home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / letters_fj / text0025.txt < prev    next >
Encoding:
Text File  |  1995-10-04  |  4.1 KB  |  103 lines
  1. Hi,
  2.  
  3. > I don't understand  totally what you mean here ...
  4. > What do you mean by the full version with large table ?
  5.  
  6. The original DVIEW code always used a couple of really large arrays to
  7. keep information about what horizontal and vertical lines to draw. After
  8. everything had been calculated it then walked through the arrays drawing
  9. first all celings, then all floors and finally all walls.
  10.  
  11. The arrays I'm talking about are mainly:
  12. short intersections[50][320];    /* 16000 16 bit integers */
  13. wall_run walls[8000];            /* 24000 16 bit integers */
  14. floor_run floorlist[200][40];    /* 32000 16 bit integers */
  15.  
  16. As you can see they are _large_. If we're going to put the drawing engine
  17. in the DSP something drastic has to be done about them.
  18.  
  19. > What do you mean by my optimized one ?
  20.  
  21. The tables I mentioned above were almost eliminated when I changed DVIEW
  22. to draw everything as soon as it was calculated. This mostly works very
  23. nicely (take a look at the drawing in single step mode), but the checks
  24. against previously drawn walls sometimes fails.
  25. I believe the failures should be easy to fix, but since I've spent several
  26. hours on it without success, I might be wrong.
  27.  
  28. > I mean : Which one is the best for the game ? ( with no bugs, speed,...),
  29.  
  30. At the moment the speed is about the same, but the memory requirements are
  31. much smaller for the direct drawing approach. I doubt the other one will
  32. be possible to implement on the DSP, but on the other hand I also doubt
  33. that the sprite drawing can be accomplished without at least most of those
  34. tables...
  35. Anyway, this is only the parts that do the actual drawing and the step
  36. immediately above that. All BSP tree searching, clipping and 3D calculations
  37. are the same, so those would be quite safe to convert to assembly.
  38.  
  39. > and I don't want to recode everything everytime, so I would like to see
  40. > the code you fell the most interesting for the game.
  41.  
  42. The changes are not really very great since the optimized version simply
  43. uses some information directly instead of putting it in a table.
  44. As for what's most interesting for the game, I'm not sure. The direct
  45. approach has definite advantages if you only need to draw the environment
  46. but it might not be enough to include the sprites.
  47. I discussed some of these things with Bertrand yesterday and I'll try to
  48. make those letters available on the mailinglist.
  49.  
  50. > Anything else, if you can, tell me which functions do you thing that won't 
  51. > be modified a lot and which ones will be changed frequently, I'll code the
  52. > first ones before.  
  53.  
  54. In view.c, DrawNode and DrawSSector are unlikely to change. You should
  55. probably try to get rid of the recursion in DrawNode, though. These two
  56. functions, together with those called in the if-statements in DrawNode
  57. are the BSP traversal itself. The algorithm can probably be improved. I 
  58. even think some suggestions are in the code somewhere.
  59. Also in view.c, LoadSeg does all the 3D calculations and clipping, which
  60. is unlikely to change. Again the algorithms used can probably be improved.
  61.  
  62. > Do you know where I can fing Gcc ?
  63.  
  64. On every ftp site I've seen, but I don't know about BBSes, especially not
  65. in France.  ;-)
  66.  
  67. > By clip the wall, I mean impossibility to walk through them.
  68.  
  69. OK, I'll try to fix that. As I said it'll be done completely outside the
  70. drawing engine since it's only a matter of not allowing the player to
  71. move everywhere.
  72.  
  73. > I'd like to see what dview would look like with textured walls.
  74.  
  75. Who wouldn't.   ;-)
  76.  
  77. > The last problem is that I've tried twice to subscribe the mailing list, 
  78. > but it didn't work, I received twice a message like unknown adress...
  79.  
  80. This is very strange. It worked when I tried it yesterday, but today I
  81. also get some kind of 'unknown mailer error 1'.
  82. I'll try to fix it ASAP and let you know when it seems to work again.
  83.  
  84. > Is 'bad_mood-request@rand.thn.htu.se' the correct adress ?
  85.  
  86. Yes.
  87.  
  88. > Other explanation ?
  89.  
  90. Not yet...
  91.  
  92. Regards,
  93. Johan
  94.  
  95.  
  96. -- 
  97.   Chalmers University   | Why are these |  e-mail:   d8klojo@dtek.chalmers.se
  98.      of Technology      |  .signatures  |            rand@cd.chalmers.se
  99.                         | so hard to do |  www/ftp:  rand.thn.htu.se
  100.    Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)
  101.  
  102.  
  103.